In , an Ethernet frame is a data link layer protocol data unit and uses the underlying Ethernet physical layer transport mechanisms. In other words, a network packet on an Ethernet link transports an Ethernet frame as its payload.
An Ethernet frame is preceded by a preamble and start frame delimiter (SFD), which are both part of the Ethernet packet at the physical layer. Each Ethernet frame starts with an Ethernet header, which contains destination and source as its first two fields. The middle section of the frame is payload data including any headers for other protocols (for example, Internet Protocol) carried in the frame. The frame ends with a frame check sequence (FCS), which is a 32-bit cyclic redundancy check used to detect any in-transit corruption of data.
The internal structure of an Ethernet frame is specified in IEEE 802.3. The table below shows the complete Ethernet packet and the frame inside, as transmitted, for the payload size up to the MTU of 1500 octets. Some implementations of Gigabit Ethernet and other higher-speed variants of Ethernet support larger frames, known as .
+ 802.3 Ethernet packet and frame structure | |
Length (octets) | 12 |
Layer 2 Ethernet frame | (not part of the frame) |
Layer 1 Ethernet packet & IPG | ← 12 octets → |
The optional 802.1Q tag consumes additional space in the frame. Field sizes for this option are shown in brackets in the table above. IEEE 802.1ad (Q-in-Q) allows for multiple tags in each frame. This option is not illustrated here.
PHY (PHY for short) is required to connect the Ethernet MAC to the physical medium. The connection between a PHY and MAC is independent of the physical medium and uses a bus from the media-independent interface (MII) family (GMII, RGMII, SGMII, XGMII, etc.). The preamble and SFD representation depends on the width of the bus:
+Preamble and SFD representations as bits, decimal, bytes, and nibbles !Representation ! colspan="14" | 56-bit (7-byte) Preamble ! colspan="2" | SFD byte | ||||||||||||||
uncoded on-the-wire bit pattern transmitted from left to right (used by Ethernet variants transmitting serial bits instead of larger symbols) | 10101010 | 10101010 | 10101010 | 10101010 | 10101010 | 10101010 | 10101010 | 10101011 | ||||||||
decimal in Ethernet LSb-first ordering | 85 | 85 | 85 | 85 | 85 | 85 | 85 | 213 | ||||||||
hexadecimal LSb-first bytes for 8-bit wide busses (GMII for Gigabit Ethernet transceivers) | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 | 0x55 | 0xD5 | ||||||||
hexadecimal LSb-first nibble for 4-bit wide busses (MII bus for Fast Ethernet or RGMII for gigabit transceivers) | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0x5 | 0xD |
The SFD is immediately followed by the destination MAC address, which is the first field in an Ethernet frame.
The EtherType field is two octets long and it can be used for two different purposes. Values of 1500 and below mean that it is used to indicate the size of the payload in octets, while values of 1536 and above indicate that it is used as an EtherType, to indicate which protocol is encapsulated in the payload of the frame. When used as EtherType, the length of the frame is determined by the location of the interpacket gap and valid frame check sequence (FCS).
The IEEE 802.1Q tag or IEEE 802.1ad tag, if present, is a four-octet field that indicates virtual LAN (VLAN) membership and IEEE 802.1p priority. The first two octets of the tag are called the Tag Protocol IDentifier (TPID) and double as the EtherType field indicating that the frame is either 802.1Q or 802.1ad tagged. 802.1Q uses a TPID of 0x8100. 802.1ad uses a TPID of 0x88a8.
Per the standard, this computation is done using the left shifting CRC-32 (polynomial = 0x4C11DB7, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x38FB2284) algorithm. The standard states that data is transmitted least significant bit (bit 0) first, while the FCS is transmitted most significant bit (bit 31) first. An alternative is to calculate a CRC using the right shifting CRC-32 (polynomial = 0xEDB88320, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x2144DF1C), which will result in a CRC that is a bit reversal of the FCS, and transmit both data and the CRC least significant bit first, resulting in identical transmissions.
The standard states that the receiver should calculate a new FCS as data is received and then compare the received FCS with the FCS the receiver has calculated. An alternative is to calculate a CRC on both the received data and the FCS, which will result in a fixed non-zero verify value. (The result is non-zero because the CRC is post complemented during CRC generation). Since the data is received least significant bit first, and to avoid having to buffer octets of data, the receiver typically uses the right shifting CRC-32. This makes the verify value (sometimes called magic check) 0x2144DF1C.
However, hardware implementation of a logically right shifting CRC may use a left shifting Linear Feedback Shift Register as the basis for calculating the CRC, reversing the bits and resulting in a verify value of 0x38FB2284. Since the complementing of the CRC may be performed post calculation and during transmission, what remains in the hardware register is a non-complemented result, so the residue for a right shifting implementation would be the complement of 0x2144DF1C = 0xDEBB20E3, and for a left shifting implementation, the complement of 0x38FB2284 = 0xC704DD7B.
+ Ethernet frame differentiation |
Any |
0xFFFF |
Other |
0xAAAA |
There are several types of Ethernet frames:
The different frame types have different formats and MTU values but can coexist on the same physical medium. Differentiation between frame types is possible based on the table on the right.
In addition, all four Ethernet frame types may optionally contain an IEEE 802.1Q tag to identify what VLAN it belongs to and its priority (quality of service). This encapsulation is defined in the IEEE 802.3ac specification and increases the maximum frame by 4 octets.
The IEEE 802.1Q tag, if present, is placed between the Source Address and the EtherType or Length fields. The first two octets of the tag are the Tag Protocol Identifier (TPID) value of 0x8100. This is located in the same place as the EtherType/Length field in untagged frames, so an EtherType value of 0x8100 means the frame is tagged, and the true EtherType/Length is located after the Q-tag. The TPID is followed by two octets containing the Tag Control Information (TCI) (the IEEE 802.1p priority (quality of service) and VLAN id). The Q-tag is followed by the rest of the frame, using one of the types described above.
As this industry-developed standard went through a formal IEEE standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard. Since the recipient still needs to know how to interpret the frame, the standard required an IEEE 802.2 header to follow the length and specify the type. Many years later, the 802.3x-1997 standard, and later versions of the 802.3 standard, formally approved of both types of framing. Ethernet II framing is the most common in Ethernet local area networks, due to its simplicity and lower overhead.
In order to allow some frames using Ethernet II framing and some using the original version of 802.3 framing to be used on the same Ethernet segment, EtherType values must be greater than or equal to 1536 (0x0600). That value was chosen because the maximum length of the payload field of an Ethernet 802.3 frame is 1500 octets (0x05DC). Thus if the field's value is greater than or equal to 1536, the frame must be an Ethernet II frame, with that field being a type field. If it's less than or equal to 1500, it must be an IEEE 802.3 frame, with that field being a length field. Values between 1500 and 1536, exclusive, are undefined.
Novell NetWare used this frame type by default until the mid-nineties, and since NetWare was then very widespread, while IP was not, at some point in time most of the world's Ethernet traffic ran over raw 802.3 carrying IPX. Since NetWare 4.10, NetWare defaults to IEEE 802.2 with LLC (NetWare Frame Type Ethernet_802.2) when using IPX. ( HTML-formatted version ) — a classic series of Usenet postings by Novell's Don Provan that have found their way into numerous FAQs and are widely considered the definitive answer to the Novell Frame Type usage.
IEEE 802.2 LLC encapsulation is not in widespread use on common networks currently, with the exception of large corporate NetWare installations that have not yet migrated to NetWare over IP. In the past, many corporate networks used IEEE 802.2 to support transparent translating bridges between Ethernet and Token Ring or FDDI networks.
There exists an Internet standard for encapsulating IPv4 traffic in IEEE 802.2 LLC SAP/SNAP frames.
In IEEE 802.3x-1997, the IEEE Ethernet standard was changed to explicitly allow the use of the 16-bit field after the MAC addresses to be used as a length field or a type field.
The AppleTalk v2 protocol suite on Ethernet ("EtherTalk") uses IEEE 802.2 LLC + SNAP encapsulation.
The throughput may be calculated from the efficiency
Channel utilization is a concept often confused with protocol efficiency. It considers only the use of the channel, disregarding the nature of the data transmittedeither payload or overhead. At the physical layer, the link channel and equipment do not know the difference between data and control frames. We may calculate the channel utilization:
The total time considers the round-trip time along the channel, the processing time in the hosts and the time transmitting data and acknowledgements. The time spent transmitting data includes data and acknowledgements.
|
|